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(57) Abstract 

The invention relates 
to mobility management of an 
Internet-type protocol traffic 
in a mobile communications 
system. At least one mobile 
exchange (DXT1, DXT2) in 
the mobile communications 
system is arranged to 
operate as a gateway which 
interfaces (router 1) the mobile 
communications system 
with external data networks. 
All the mobile exchanges 
(DXT1, DXT2) are arranged 
to use a user identity and a 
data equipment identity for 
identifying each mobile host 
and to use an identity of the 
mobile exchange currently 
serving the mobile host for 
defining the location of the 
mobile host. Each mobile host 
is dynamically or permanently 

allocated an IP address which 

is bound to the user identity, 
the data equipment identity 

and the location information of the respective mobile host. The use of the user identity and the data terminal identity provide a unique 
identification for the mobile host without any relation to the IP network. Also the location information is independent of the IP network. 
As a consequence, the mobile exchanges are able to route IP datagrams having the allocated IP address from a gateway exchange (DXT1) 
to the serving exchange (DXT2) according to the location information and further to the respective mobile host according to the user 
identity and the data equipment identity bound to the IP address by using a mobile network specific routing method instead of mobile IP 
tunnelling. 
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ARRANGEMENT FOR SECURE COMMUNICATION AND KEY DISTRIBUTION IN A TELECOMMUNICATION 

SYSTEM 

Field of the Invention 

The invention relates to mobility management of an Internet-type 
protocol traffic in a mobile communications system. 

5 Background of the Invention 

Mobile communications system refers generally to any telecommu- 
nications system which enables wireless communication when users are 
moving within the service area of the system. A typical mobile communications 
system is a Public Land Mobile Network (PLMN). Often the mobile communica- 

10 tions network is an access network providing a user with wireless access to 
external networks, hosts, or services offered by specific service providers. 

One of the main targets in the development of mobile communica- 
tions networks is to provide the user with IP (Internet Protocol) service, i.e. ac- 
cess to the Internet through a mobile communication network. It is desired that 

15 the IP will be implemented as an overlay of the mobile network, while back- 
wards compatibility with present systems is maintained with minimal modifica- 
tions in the present standards. However, a problem is that the basic IP con- 
cept does not support user mobility: the IP addresses are assigned to network 
interfaces on the basis of their physical location. In fact, the first field of an IP 

20 address (the NETID) is common to all interfaces that are linked to the same 
Internet subnet. This scheme prevents the user (the mobile host) from keeping 
his/her address when moving in different Internet subnets, i.e. when changing 
the physical interface. 

In order to enhance mobility in the Internet, a Mobile IP protocol for 

25 IP version 4 has been introduced by the Internet Engineering Task Force 
(IETF) in the standard RFC2002. The mobile IP enables the routing of IP da- 
tagrams to mobile hosts independently of the point of attachment in the sub- 
network. The mobile IP protocol introduces the following new functional or ar- 
chitectural entities. 

30 'Mobile Node MN' (also called Mobile Host MH) refers to a host that 

changes its point of attachment from one network or subnetwork to another. A 
mobile node may change its location without changing its IP address; it may 
continue to communicate with other Internet nodes at any location using its 
(permanent) IP address. 'Mobile Station (MS) 1 is a mobile node having a radio 

35 interface to the network. A Tunnel' is the path followed by a datagram when it 
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is encapsulated. The encapsulated datagram is routed to a known decapsula- 
tion agent, which decapsulates the datagram and then correctly delivers it to 
its ultimate destination. Each mobile node is connected to a home agent over 
a unique tunnel, identified by a tunnel identifier which is unique to a given For- 
5 eign Agent/Home Agent pair. 

'Home Network' is the IP network to which a user logically belongs. 
Physically, it can be e.g. a local area network (LAN) connected via a router to 
the Internet. 'Home Address' is an address that is assigned to a mobile node 
for an extended period of time. It may remain unchanged regardless of where 

10 the MN is attached to the Internet. Alternatively, it could be assigned from a 
pool of addresses. 

'Mobility Agent' is either a home agent or a foreign agent. 'Home 
Agent HA' is a routing entity on a mobile node's home network which tunnels 
packets for delivery to the mobile node when it is away from home and main- 

15 tains current location information for the mobile node. It tunnels datagrams for 
delivery to, and, optionally, detunnels datagrams from, a mobile node when 
the mobile node is away from home. 'Foreign Agent FA* refers to a routing en- 
tity in a mobile node's visited network which provides routing services to a 
registered mobile node, thus allowing the mobile node to utilise its home net- 

20 work address. The packets tunnelled by the mobile node's home agent are 
detunnelled and delivered to the mobile node by the foreign agent. For data- 
grams sent by the mobile node, the foreign agent may serve as a default 
router for registered mobile nodes. 

RFC2002 defines 'Care-of Address' (COA) as the termination point 

25 of a tunnel toward a mobile node, for datagrams forwarded to the mobile node 
when it is away from home. The protocol can use two different types of care-of 
addresses: a "foreign agent care-of address" is an address announced by a 
foreign agent with which the mobile node is registered, and a "co-located care- 
of address" is an externally obtained local address which the mobile node has 

30 acquired in the network. An MN may have several COAs at the same time. An 
MN's COA is registered with its HA. The list of COAs is updated when the mo- 
bile node receives advertisements from foreign agents. If an advertisement 
expires, its entry or entries should be deleted from the list. One foreign agent 
can provide more than one COA in its advertisements. 'Mobility Binding' is the 

35 association of a home address with a care-of address, along with the remain- 
ing lifetime of that association. An MN registers its COA with its HA by sending 
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a Registration Request. The HA replies with a Registration Reply and retains a 
binding for the MN. 

The article "Performance Evaluation of Mobile IP Protocols in a 
Wireless Environment", Maurizio Dell' Abate et al, IEEE International Confe- 
5 rence on Communications, 1998, Conference Record, 1998, p. 1810-1816, 
discloses a Route Optimization MIP scheme which enhances the basic mobile 
IP (MIP). According to ROMIP, packets addressed to a particular host can be 
tunnelled directly from the source so that the intervention by the home agent is 
bypassed. The ROMIP allows every traffic source to cache and use binding 

10 copies. The original binding for a mobile host is kept in its home agent, but 
ROMIP supports a further update process in which the binding copy (current 
COA of the mobile host) is sent to the source host, normally in response to a 
first IP packet sent to a mobile host not located in the home network. The 
source host caches the received binding and uses it to tunnel the packet to a 

15 foreign agent FA indicated by the COA. When the destination mobile host 
suddenly moves to another subnet and under another foreign agent, the mo- 
bile host sends, immediately after it has moved, the binding update messages 
both to the home agent HA and the previous foreign agent FA. The source 
host has no way to become aware of the movement and it keeps sending IP 

20 packets to the old FA. These packets get lost until the old FA receives the 
above update. As soon as the old FA gets updated, it warns the source host 
and forwards incoming packets to the new FA. The handover ends when the 
source host, having received a fresh binding from the home agent HA, can 
tunnel its packets directly to the new FA. 

25 The article "Mobile Internet Access and QoS Guarantees Using 

Mobile IP and RSVP with Location Registers", Ravi Jain et al, IEEE Internatio- 
nal Conference on Communications, 1998, Conference Record, 1998, p. 
1690-1695, discloses an alternative route optimization protocol, namely Mobile 
IP with Location Registers (MIP-LR). According to the MIP-LR, before launch- 

30 ing a packet to a mobile host, a sending host first queries a database about 
the current location of the addressed mobile host. More particularly, when a 
mobile host moves from one subnet to another, it registers its current COA in a 
database called a Home Location Register (HLR). When a sending host has a 
packet to send, it first queries the HLR to obtain the mobile host's COA, and 

35 then sends packets directly to the mobile host. The location of the mobile host 
is also maintained in another database, a Visitor Location Register (VLR) in a 
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visited subnetwork. Two mechanisms are proposed for updating the location of 
the mobile host in a cache of the sending host when the mobile host moves. In 
a first mechanism the mobile host informs the old VLR which traps any pack- 
ets destined to the old COA and sends a binding warning message to the 
5 HLR. The HLR sends a binding update message containing the mobile host's 
new COA to the sending host. In a second mechanism the mobile host main- 
tains a list of all the other hosts it has active connection with, and sends a 
binding update to each such host. 

Neither of these prior art mobility management schemes is abso- 

10 lutely suitable for implementing IP mobility management in a mobile communi- 
cation system which does not employ IP as a network protocol. The TETRA 
network, which tunnels IP traffic through a non-IP protocol, is an example of 
such a system. The TETRA system is a digital mobile communication system 
developed primarily for professional and governmental users, such as the po- 

15 lice, the military, oil plants, etc. The mobility management problem will now be 
illustrated with reference to Fig. 1 which shows a TETRA network connected to 
the Internet. The TETRA network comprises digital exchanges DXT and 
TETRA base stations TBS. There are two possible configurations of how a 
DXT can be connected to the internet. In the first configuration each DXT unit 

20 may have its own direct "exit" via an adjacent router, such as router 1 for DXT1 
and router 2 for DXT2 in Fig. 1, for forwarding IP packets from the TETRA 
network to the Internet and vice versa. In the second configuration only one or 
some of the DXT units, referred to as gateway DXTs herein, are connected to 
an Internet router (e.g. DXT1 to router 1 in Fig.1), and the other DXTs are 

25 connected to the Internet over these gateway DXTs. 

Internet routers see TETRA networks as ordinary local IP networks. 
Each TETRA network is assigned a set of unique IP addresses (IPv4 ad- 
dresses, for example). The IPv4 address is composed of 32 bits and pre- 
sented as a network and host identifier pair. The network identifier (netid) 

30 specifies a TETRA IP network and the host identifier specifies a mobile host in 
the TETRA network. In the TETRA network, an IP subnetwork can be formed 
around one or multiple DXTs. In the latter case, several DXTs will be logically 
organized under the same netid prefix and will share the same host address 
space. In the example illustrated in Fig. 1 , a TETRA subnetwork 1 is formed 

35 around DXT1 and assigned a netid '192.1.1.0', and a TETRA subnetwork 2 is 
formed around DXT2 and assigned a netid '192.1.2.0'. The organization of IP 
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networks around DXTs requires routing capabilities on the links between them. 
Each single- or multi-DXT network must be able to forward datagrams des- 
tined to other TETRA IP networks. In Fig. 1 the DXT1 and the DXT2 are inter- 
connected by a link 10. 
5 The mobile hosts may move from one cell to another and thereby 

arbitrarily roam between the DXTs. The mobile host may start an IP data ex- 
change in one network and complete it in another. The movement of the mo- 
bile hosts among TETRA networks leads to a situation where the netid identi- 
fier in the IP address of the mobile does not necessarily correspond to the cur- 
io rent network. The IP address of the mobile host will not correspond to any 
TETRA network if the user has an IP subscription to another network than the 
TETRA. Further, the basic Internet routing protocols choose routes based on 
the destination network identifier but do not support mobility. If TETRA net- 
works utilize only standard internet routing protocols, IP datagrams will not 
15 reach roaming users. 

The Mobile IP solves the mobility management problem of the basic 
IP by adapting to the inflexibility of the IP address, therefore it is not fully appli- 
caple to the TETRA network. Some of the mobile IP features unfavourable to 
the TETRA are listed below: 
20 - In the mobile IP, the mobile host is identified with re- 

spect to its home IP network, whereas in the TETRA the mobile 
user is identified by both an individual subscriber identity and a 
network service point identifier (NSAPI). 

- In the mobile IP, the mobile host is associated with its 
25 home network and dependent on the home agent. In the TETRA 

this would imply that the mobile host must be bound to a particular 
network. The dependence on that network reduces the robustness 
of the IP service as a whole. If the home agent is unreachable at 
the time when the mobile host, located in a visited network, ac- 
30 quires an IP address, the IP service will be denied. The availability 

and robustness of the service is especially essential in the TETRA 
which is used by the police, the fire service, etc., for emergency and 
command purposes. 

- In the mobile IP, the location of the mobile host is de- 
35 fined by the network identifier of the current IP network. In the 

TETRA this would mean that the movement of the mobile host can 
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be detected only if the mobile host moves from one IP network to 
another. If there is an intention to reuse the existing TETRA infra- 
structure, then each DXT must be associated with a certain IP net- 
work identifier in order to bind the IP network numbers with the 
5 TETRA network topology. Each DXT must be equipped with TCP/IP 

stack and must participate in unnecessary IP tunneling that intro- 
duces an IP overhead in each tunneled datagram (a basic unit of 
information passed in an IP packet). We must also send, or broad- 
cast, MIP messages enclosed in IP packets over the air interface. 
10 This will load a poor radio interface link and introduce a 40-byte 

overhead in each message. The tunneling could be justified only if 
the TETRA network would utilize Internet routing protocols anyway. 
The tunneling also means that the traffic flow towards the mobile 
host must be passed through the home agent making the IP service 
15 more vulnerable to a failure of the home agent. 

- In the mobile IP, the mobile host must carry out an 
authentication and location update procedure every time it moves to 
another network. In the TETRA this introduces an additional data 
exchange over the air interface. Further, the TETRA utilizes specific 
20 authentication and location update procedures. 

Also the enhanced ROMIP and MIP-LR protocols described in the 
above mentioned articles are unsuitable to the TETRA. The prior art methods 
have two features in common: 1) The protocols are designed for IP networks 
and adapted to the IP environment, consequently both protocols associate the 
25 user location with the IP network identifier, 2) The protocols handle mobility in 
an end-to-end manner, meaning that both communicating ends must take care 
of mobility management. Therefore, despite the optimizations introduced by 
the methods, all the inconsistent features which are described above with re- 
spect to the basic MIP are also valid for ROMIP and MIP-LR. Further, the 
30 ROMIP and MIP-LR can be applied only if both communicating ends support 
the ROMIP or MIP-LR protocol. Otherwise the communication falls back to the 
conventional MIP. A further major disadvantage in the ROMIP and MIP-LR 
relates to handover. The mobile host itself discovers a visited network after 
having received an advertisement from Foreign Agent. This introduces a cer- 
35 tain idle period when none of the agents (Home Agent, old Foreign Agent and 
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new Foreign Agent) knows the real location of the mobile host. During that pe- 
riod an appropriate agent discards datagrams destined to the mobile host. 

Disclosure of the Invention 

5 An object of the invention is to provide an IP mobility management 

method and a mobile communication system which overcome or alleviate the 
above described problems. 

This and other objects of the invention are achieved with a method 
and a system which are characterized by what is disclosed in the attached in- 

10 dependent claims. Preferred embodiments of the invention are disclosed in the 
attached dependent claims. 

In the present invention the mobile host is identified by a unique 
pair of a user identity and a data equipment identity which are bound to an IP 
allocated to a mobile host in the system. The user identity enables to bind the 

15 allocated IP address to a specific end user or to a specific mobile station in the 
mobile communication system. In a preferred embodiment of the invention the 
user identity is a mobile subscriber identity. The end data equipment identity 
enables to distinguish between several data equipments connected to the one 
and the same mobile station. In the preferred embodiment of the invention a 

20 network service access point identifier (NSAPI) is used for this purpose. In this 
context, the term 'end data equipment* refers to any data equipment or IP ap- 
plication connected to, integrated into or associated with a mobile station. The 
use of the user identity and the data terminal identity provide a unique identifi- 
cation for the mobile host without any relation to the IP network. Further, in 

25 most communication systems, such as TETRA, this allows to re-use the iden- 
tities already available in the communication system. 

Further, according to the present invention, the location of the mo- 
bile host is defined by the identity of the mobile exchange currently serving the 
mobile host. The identity of the mobile exchange uniquely identifies a node in 

30 the fixed part of the mobile communication network, whereas the mobile ex- 
change, in accordance with the mobility management procedures employed in 
the communication network, knows the location of the mobile host within the 
service area of the exchange. Also the location information is bound to the al- 
located IP address of the mobile host. As a result, an IP datagram having the 

35 allocated IP address can be routed to the serving exchange according to loca- 
tion information bound to the IP address in the mobile communication network. 
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The serving mobile exchange is then able to forward the datagram to the des- 
tination mobile host according to the user identity and the entry terminal iden- 
tity bound to the allocated IP address. This inventive concept allows to use a 
mobile network specific routing method instead of mobile IP tunnelling. Thus, 
5 also implementation of the TCP/IP stack in each network node and conse- 
quently, the drawbacks of the mobile IP are avoided. 

A further advantage of the location management according to the 
present invention is that handovers within the mobile communication network 
are transparent to external networks. In other words, the gateway to an exter- 

10 nal network can be maintained as an anchor point, and the datagrams are only 
rerouted within the mobile communication network to the new location. As the 
IP address remains unchanged for the time the mobile host is registered to the 
mobile communications network, no updatings from the mobile host to the ex- 
ternal network are needed due to handovers. 

15 Further, in the present invention the mobile communications net- 

work may allocate the IP address to the mobile host from a set of available 
address spaces. The allocation of the IP address may be permanent (fixed) or 
the allocation may be carried out dynamically when the mobile host registers 
to the network. The available address spaces may be distributed over several 

20 exchanges. Further, if a serving exchange is unable to allocate the IP address 
it may acquire the IP address from another exchange. As a result, the avail- 
ability of the IP service is assured, because the mobile host is not dependent 
on the links to the home network and availability of the home agent, as in the 
mobile IP. 

25 The mobility management of the invention also supports a location 

update between mobile exchanges in the mobile communication system. In an 
embodiment of the present invention the handover is started at the old ex- 
change which informs a new exchange about the new mobile host and trans- 
fers the associated user identity and the associated end data terminal identity 

30 to the new exchange. In the preferred embodiment of the invention the old ex- 
change stores the new location of the mobile host for a certain period of time, 
in order to enable routing of any subsequent datagram to the new exchange. 
These schemes enable to avoid the idle period encountered in the mobile IP 
and to make the handovers smoother, thereby reducing datagram loss to 

35 minimum. 
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In a still further embodiment of the invention the location of the mo- 
bile host is updated also at the exchange that manages the allocation of IP 
addresses from the IP address space to which the allocated IP address be- 
longs, if the managing exchange is not one of the exchanges participating with 
5 the handover. The gateway exchange, or any other exchange which wishes to 
route an IP datagram having an IP address with an unknown location, may re- 
quest the location information from the respective managing exchange and 
route the datagram, and any subsequent datagrams, to the obtained location. 
Also in the gateway exchange the obtained location information will be stored 

10 only for a predetermined period of time and will be deleted when the period of 
time expires. If a further datagram having the allocated IP address is received 
after the deletion of the location information, the gateway will send a new loca- 
tion information request to the managing exchange. The gateway will also re- 
route the new datagrams to a new location after having received a location 

15 update from the old exchange. These measures will assure that the location 
information and the routing path are kept up-to-date. 

Brief Description of the Drawings 

In the following, the invention will be described in greater detail by 
20 means of preferred embodiments and with reference to the accompanying 
drawings, in which 

Figure 1 illustrates a TETRA network connected to the Internet, 
Figure 2 shows an address table, 

Figure 3 is a signalling diagram illustrating the transfer of the user 
25 IP context in a handover, 

Figure 4 is a signalling diagram illustrating the transfer of the user 
IP context and the location update to the APS in a handover, 

Figure 5 is a signalling diagram illustrating the acquirement of the 
location for an IP address, 
30 Figure 6 is a signalling diagram illustrating the update of the ad- 

dress table in a forwarding DXT, 

Figure 7 illustrates a scenario where a mobile host roams from an 
APS to an APC and vice versa, the APC being" connected to the Internet 
router, 

35 Figure 8 illustrates a scenario where the mobile host roams be- 

tween two APCs, 
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Figure 9 illustrates a scenario of how the mobility management ac- 
cording to the invention may be conducted in a four-DXT network where only 
one DXT is connected to the Internet and the mobile host moves from an APC 
to another, 

5 Figure 10 illustrates a second scenario for the mobility management 

according to the invention in a four-DXT network where only one DXT is con- 
nected to the Internet and the mobile host roams from one APC to another, 

Figure 11 illustrates a scenario of conducting the mobility manage- 
ment according to the present invention in a three-DXT network where only 
to one DXT is connected to the Internet. 

Preferred Embodiments of the Invention 

The present invention can be generally applied to mobile communi- 
cations systems for providing IP mobility. The invention can be particularly ad- 

15 vantageously used for providing IP mobility management in a mobile telecom- 
munications system that employs a non-IP protocol for routing IP traffic. The 
TETRA network is an example of such a system. In the following, the preferred 
embodiments of the invention will be described by means of the TETRA sys- 
tem without limiting the invention to this particular mobile communications 

20 system. 

The MH may consist of a laptop computer PC connected to a mo- 
bile station radio. Alternatively, the MH can be an integrated combination of a 
small computer and a cellular telephone, similar in appearance to the Nokia 
Communicator 9000 series. Yet further embodiments of the MH are various 

25 pagers, remote-control, surveillance and/or data-acquisition devices, etc. 

An. example of the possible TETRA architecture is described above 
with reference to Fig. 1. It should be understood that Fig. 1 only shows a sim- 
plified architecture suitable for the description of the present invention. In 
practice, the TETRA system may include any number of TBSs, DXTs, MHs 

30 and routers, as well as other network elements which are relevant to the pres- 
ent invention. As used herein, the TETRA IP network is a collection of DXTs 
that share the same IP address network prefix. One TETRA network may be 
subdivided into two or more TETRA IP networks. The protocol which manages 
the IP service in the TETRA and includes the IP mobility management ac- 

35 cording to the present invention is called an Address Information Protocol 
(AIP) herein. The AIP protocol resides on the top of the TETRA transport 
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layer. Consequently, it exchanges control messages with peers utilizing the 
underlying transport service. The protocol is not required to route datagrams 
over the shortest path. Local processes can request IP address information 
from the AIP at least in two cases. Firstly, when the user is requesting the IP 

5 service, the process that is responsible for resource allocation requests the 
AIP for an IP address. Secondly, before the TETRA routing process forwards 
the IP datagram, it requests the AIP for the current location associated with 
the destination IP address. The location of the mobile host is specified with the 
identification number of a TETRA network node. In the preferred embodiment, 

10 location is defined in the IP service with the identity (address) of the DXT ex- 
change. 

A TETRA IP network can be configured around a dedicated DXT by 
assigning an IP network identifier. All the IP addresses that are available un- 
der the assigned network identifier are called the address space. The AIP en- 

15 tities allocate IP addresses to users from the available address spaces. The 
allocated IP addresses with their associations are stored in a data structure 
called an address table. The address space may be divided into static and dy- 
namic address subspaces. The static IP addresses are individually assigned 
to particular users. The AIP entity, which is assigned an IP network identifier, 

20 is called an Address Pool Server (APS) and an AIP entity without an IP net- 
work identifier is called an Address Pool Client (APC). Both the APS and APC 
may co-exist in the AIP process unit. The AIP entity acts as the APC in the 
following cases: 1) The AIP is not assigned an address space (the AIP is a 
pure APC), 2) the AIP is assigned an address space, but the address pools 

25 are currently exhausted, and 3) The user has no permission to acquire IP ad- 
dresses from local address pools. If for some reason the AIP cannot allocate 
an IP address from the local address space, it may acquire an address from a 
remote APS. 

When the APS or APC issues an IP address to the user, it creates 
30 an entry in the address table for storing the IP address and the current user 
location. In order to allocate an IP address, the AIP must know both the user 
identifier and the identifier of the end data equipment or application. The for- 
mer identifier is necessary to bind the IP address either to the end user or to 
the end mobile station. The Individual Short Subscriber Identity (SSI) number 
35 may serve for this purpose. The latter identifier is necessary to distinguish 
between several data equipment (or applications) connected to one and the 
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same mobile station. The Network Service Access Point Identifier (NSAPI) 
may be used for this purpose. An example of a possible address table with a 
minimal set of fields is shown in Fig. 2. The IP Address entry field lists all allo- 
cated IP addresses. The Location DXT field indicates the current locations of 
5 the IP users. The Static/Dynamic field shows whether or not the address is 
permanently assigned to a user. The User Identifier field associates IP ad- 
dresses with end users. The NSAPI (Network Service Access Point Identifier) 
field identifies the end data equipment. In the TETRA network, the user may 
simultaneously use up to 13 data equipment. The number 0 is reserved for a 

10 special use and number 15 for multicast. Consequently, there may be more 
than one entry for one and the same user, i.e. the same SS1 (e.g. SSI A in 
Fig. 2) but different NSAPIs and IP addresses (e.g. IP address '192.1.1.1' and 
NSAPI 1 as well as IP address '192.1.1.52' in Fig. 2) 

The entry (entries) of a single user in the table of Fig. 2 is herein 

15 called a user IP context of the respective user. The IP context of the user may 
contain several entries. As noted above, the user IP context is created when 
the APC or the APS issues an IP address to the user. Normally the IP address 
is issued in response to an address acquisition request from the user. The ad- 
dress acquisition request contains the user and data equipment identifiers SSI 

20 and NSAPI. When the APC or APS receives the address acquisition request 
from the mobile host, it looks up in the address table an entry indicating user 
and data equipment identifiers that match with the ones in the received re- 
quest. If the APC or the APS finds such an entry, it completes the request by 
returning the IP address to the caller. Otherwise, the APC or the APS will at- 

25 tempt to allocate an IP address from the local address space. If there is no IP 
address available in the address pool, the APC or APS sends an address ac- 
quisition request to the remote APS server. The remote APS server obtains an 
IP address from an address pool and sends it back to the requesting entity. 
The address may be issued for a predetermined period of time which may be 

30 renewed with a specific renewal procedure. The default period may be 12 
hours, for example. However, the default time should preferably be such that 
the IP address does not change during the time the mobile host is registered 
to the system. When the user no longer needs the IP address, the user re- 
quests that the entry or the IP context in the address table is deleted and the 

35 IP address is returned to the address pool. If the IP address is permanently 
allocated, it cannot be allocated to another mobile host. 
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The IP context is also transferred from one DXT to another in a 
handover situation. If, because of the handover, the user IP context is to be 
transferred to a new DXT, the mobile host notifies the AIP entity in the old DXT 
of this event by sending a roaming request message, as shown in Fig 3. The 
5 old DXT sends a roaming request ROAMINreq to the AIP entity in the new 
DXT and assigns a roaming state the entry (entries) of the roaming user in the 
old DXT. The roaming request ROAMINreq contains the SSI and the copy 
(copies) of address table entry (entries) associated with the user of the mobile 
host. Upon receiving the ROAMINreq receipt, the AIP entity in the new DXT 

10 attempts to allocate received entries in the address table. If the IP address(es) 
belong(s) to the IP address space allowed for the new DXT, the new DXT re- 
sponds to the originator with a roaming ROAMINack acknowledgement as 
shown in Figure 3. The acknowledgement contains the SSI and a list of IP ad- 
dresses allocated in the new DXT for the user of the mobile host, i.e. the same 

15 IP addresses as listed in the ROAMINreq. If more than one of the IP ad- 
dresses in the ROAMINreq fail to belong to the allowable IP address space of 
the new DXT, i.e. the same IP address is associated with another user, or the 
new DXT cannot allocate all the IP addresses, the IP address list in the 
ROAMINack does not contain the non-allocated address(es) and is inconsis- 

20 tent with the list in the ROAMINreq . 

On receipt of the acknowledgement, the AIP entity in the old DXT 
must compare these two lists. The acknowledged entries are moved to a 
LOOSING_ENTRY state and their timers are set to a routing period which may 
be equal to 40 minutes for example by default. The unacknowledged entries 

25 are deleted and their addresses are returned back to appropriate APSs. En- 
tries at the LOOSINGJENTRY state are deleted when the routing period timer 
expires. 

If the context transfer involves IP addresses allocated from the local 
address space, the AIP entity in the old DXT, which acts in this case as the 
30 APS, moves appropriate entries from an ASSOCIATED_LOCAL to a 
ROAMING_FROM_APS state. On receipt of the acknowledgement, these 
entries are moved to an ASSOCIATED_REMOTE state, and their timers are 
set to a total lease period. 

As described above, on receipt of the ROAMINreq request, the AIP 
35 entity in the new DXT attempts to allocate address entries transferred from the 
old DXT and then it acknowledges successfully allocated entries with a 
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ROAMINack. After this, if addresses have not arrived from the APS in the old 
DXT, the AIP entity initializes a location update. It sends a location update re- 
quest LOCUPDreq to the appropriate APS, as shown in Fig. 4, and moves 
these entries to an U P DATI N G_LOC ATI O N state. It is assumed that before 
5 moving the entry to this state, the AIP saves the current state of the entry. 
When the APS receives the LOCUPDreq request, it updates the location in the 
appropriate entries. The APS must always acknowledge the LOCUPDreq re- 
quest with a location update acknowledgement LOCUPDres. Yet, if the LO- 
CUPDres were lost, the AIP in the new DXT would retransmit a second loca- 

10 tion update request LOSUPDreq and return the address entry to the former 
state. If the AIP in the new DXT receives a LOCUPDres acknowledgement 
from the APS in the U P DATI N G_LO C ATI O N state, it checks the list of the ac- 
knowledged IP addresses. If. because of an exceptional condition, the APS 
cannot perform location update for some of the addresses, the list will be in- 

15 consistent with the list in the LOCUPD request and the AIP in the DXT will re- 
lease unacknowledged addresses. 

A particular service user, such as a mobile host or a DXT, may 
need to resolve IP address locations for destination IP addresses. This can 
occur occasionally when datagrams arrive to a user who has moved to an- 

20 other DXT, or regularly if the DXT is connected to an Internet router, or if mo- 
bile users are allowed to send IP datagrams to one another. The service user 
in the DXT, responsible for the routing, requests the current IP address loca- 
tion from the local AIP process (in the same DXT) by issuing a location re- 
quest, as shown in Fig. 5. When the AIP receives such a request for an IP 

25 datagram arrived from an external router or from a TBS, it checks whether 
there is already an entry associated with the IP address in the local address 
table. If such an entry is found, the AIP returns the DXT identifier to the re- 
questing entity. Otherwise, it queries the database about the APS server which 
issued the given IP address, sends an address location acquisition request 

30 ADDRLOCreq to it, and moves to an ACQUIRING DXTID state. 

The APS responses to the location acquisition request with a 
ADDRLOCres response carrying the DXT identifier or a zero, which means 
that the IP address is not currently used. In response to the LOCUPDres re- 
ceived, the AIP in the routing DXT creates an address table entry, called the 

35 routing entry, and puts the entry into a ROUTING state which sets the routing 
entry timer to a value that is one time unit less than the routing period, for ex- 
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ample. The time unit for a routing entry is a minute, for example. The default 
routing period may equal 40 minutes, and by default the timer of the routing 
entry may be set to 39 minutes, for example. The routing entry is deleted when 
the respective routing entry timer expires. The AIP in the routing DXT resets 
5 the timer every time when an address location request refers to the routing 
entry. 

If after the database call, the AIP in the routing DXT detects an un- 
known destination IP network, it will complete the request by returning the 
identifier of the default DXT gateway which connects the TETRA network to 
10 the Internet. 

When the AIP in the local DXT receives a location request for- 
warded from another DXT, and there is no entry associated with the given IP 
address in the address table, it sends a destination remove request DESREM- 
req to the AIP in the originating DXT, as shown in Fig. 6. But if the AIP in the 
15 local DXT knows where the user with a particular IP address has moved to 
(entry with specified IP address is in the LOOSING_ENTRY state), it sends an 
address destination update DESUPDreq message to the AIP in the originating 
DXT and completes the local location request, as shown at the bottom of Fig. 
6. 

20 On the DESUPDreq receipt, the AIP in the originating DXT must 

update the location field of the appropriate address entry, whereas on the 
DESREMreq receipt, the AIP in the originating DXT must delete the routing 
entry. If the APS receives a DESREMreq for one of the local addresses, it 
moves the appropriate entry from the ASSOCIATED REMOTE to a 

25 WAIT_LOCATION_UPDATE state and keeps its timer field unchanged. The 
APS deletes this entry on the timer expiration. If the APS receives a LOCUP- 
Dreq, LOSUPDreq, ROAMINreq or LEASRENreq message, it moves the entry 
back to the ASSOC IATED_REMOTE state and behaves accordingly. If the 
APS receives an ADDRLOCreq for an entry in the WAIT_LOCATION_ 

30 UPDATE state, it responds with a negative ADDRLOCres. 

In the following, several illustrative scenarios of the IP mobility 
management and routing according to the invention will be described with ref- 
erence to Figures 7-10. The network elements, i.e. the DXTs, are referred to 
by their AIP functionality, namely the address pool server (APS) and the ad- 

35 dress pool client (APC). 
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Figure 7 illustrates a scenario where a mobile host roams from an 
APS to an APC and vice versa, the APC being connected to an Internet router. 
Referring to Figure 7, an Internet router 71 is connected to an APC 72 which 
operates as a gateway. Let us assume that a mobile host that is currently lo- 
5 cated at an APS 73 has initially acquired an IP address from an APS 73. The 
mobile host has also contacted a server in the Internet to establish an IP ses- 
sion and thereby informed the allocated IP address to the server 
(correspondent host) in the Internet. Thus, no home agent is necessarily in- 
volved. 

10 When the Internet server sends the first IP datagram containing the 

allocated IP address, the IP datagram is routed via the Internet to the router 71 
and further to the gateway APC 72. The APC 72 acquires the location of the 
mobile host from the APS 73, which manages the IP address space where the 
IP address in the datagram belongs to. The APS 73 responds with the location 

15 information, i.e. the identity of the APS 73. The APC 72 also stores the loca- 
tion information for 39 minutes by default, so as to enable the routing of sub- 
sequent IP datagrams. Let us now assume that the mobile host roams from 
the APS 73 to the APC 72 and a handover is initiated. In the handover the 
APS 73 sends (74) the user IP context to the APC 72, as described above with 

20 reference to Figure 3. The APC 72 acknowledges (75) this and the APS 73 
updates the location of the mobile host in the address table. Now, when a da- 
tagram having the IP address is received at the APC 72, the APC 72 sends 
the datagram to the mobile host according to the user identity and the end 
data terminal identity in the user IP context. After a while, the mobile host 

25 roams back to the APS 73 and a handover is again initiated. The APC 72 
sends (76) the user IP context to the APS 73. The APS acknowledges (77) 
this and the APC stores the user location for 40 minutes by default. If a new 
datagram arrives from the Internet within 40 minutes, the APC 72 correctly 
forwards it to the APS 73 and sets the location information timer to 39 minutes 

30 by default. On the other hand, if a new datagram arrives after 40 minutes, the 
APC 72 has already deleted the location information for this IP address and 
therefore acquires the location information again from the APS 73. 

Figure 8 illustrates a scenario where the mobile host roams be- 
tween two APCs. Let us assume that the mobile host is initially at the APC1 

35 and acquires (80A,80B) an IP address from the APS. After a while, the mobile 
host roams to the APC2 and a handover is initiated. The APC1 sends (81) the 
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user IP context to the APC2, which the APC2 acknowledges (82). Having re- 
ceived the acknowledgement, the APC1 stores the new location of the mobile 
host for 40 minutes by default. Having sent the acknowledgement, the APC2 
sends (83) a location update request to the APS. The APS updates the user 
location and acknowledges (84) this to the APC2. Thus, the location informa- 
tion is kept updated in the different nodes of the system. 

Figure 9 illustrates a scenario of how the mobility management ac- 
cording to the invention may be conducted in a four-DXT network where only 
one DXT is connected to the Internet and the mobile host moves from one 
APC to another. In Figure 9, the APC1 is connected to the router R1 in the In- 
ternet. Let us assume that the mobile host is initially registered to the APC2 
and an Internet address is acquired (91, 92) from the APS1. The mobile host 
initiates the IP traffic. The first datagram from the Internet arrives at the APC1 
over the router R1. The APC1 requests (93, 94) the location information for the 
IP address from the APS1. The APC1 stores the location in the cache for 39 
minutes by default and returns the location to the TETRA routing process 
which routes the datagram to the APC2. Each time a datagram arrives, the 
APC1 restarts the timer for the cached location. After a while, the mobile host 
moves from the APC2 to the APC3 and a handover is initiated. In the hando- 
ver the APC2 sends the user IP context (95) to the APC3 and the APC3 ac- 
knowledges (96) this. Having received the acknowledgement, the APC2 stores 
the new location in the cache for 40 minutes by default. When the APC3 has 
completed the handover, it starts a location update procedure (97, 98) to up- 
date the location on the mobile host at the APS1. Now a new datagram from 
the Internet arrives at the APC1. The APC1 forwards the datagram to the 
APC2 according to the location in the cache. Since the APC2 knows the new 
location of the mobile host, it forwards the datagram to the APC3. After this the 
APC2 sends a destination update request (99) to the APC1 in order to update 
the location information at the APC1. The APC1 caches the new location. As 
new datagrams arrive, the APC1 forwards them directly to the APC3. 

Figure 10 illustrates a second scenario for the mobility management 
according to the invention in a four-DXT network where only one DXT is con- 
nected to the Internet and the mobile host roams from one APC to another. 
The second scenario is similar to the first one described with respect to Figure 
9 up to the updating of the location (97, 98) at the APS1 by the APC3. The 
mobile host is now at the APC3. A new datagram from the Internet arrives at 
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the APC1. The APC1 forwards the datagram to the APC2 and restarts the 
timer for 39 minutes. Since the APC2 knows the new location, it forwards the 
datagram to the APC3. After this the APC2 sends a destination update request 

(99) to the APC1 in order to update the location at the APC1. However, be- 
5 cause of a link failure the APC1 does not receive the destination update re- 
quest (99), and the location is not updated. Forty minutes later the APC1 re- 
ceives a new datagram. The APC1 forwards the datagram to the APC2 ac- 
cording to the location information in the cache of the APC1. Since the location 
timer in the APC2 has expired, the location information has been deleted and 

10 the APC2 no longer knows the new location of the mobile host. As a conse- 
quence, the APC2 discards the datagram and sends a destination remove re- 
quest (100) to the APC1. Having received the destination remove request 

(100) , the APC1 deletes the location of the mobile host in the cache. When a 
new datagram arrives at the APC1, the APC1 acquires the new location from 

15 the APS1 as described above. 

Figure 11 illustrates a scenario of conducting the mobility manage- 
ment according to the present invention in a three-DXT network where only 
one DXT is connected to the Internet. In Figure 11, the APS is connected to 
the router R1 in the Internet. Let us assume that the mobile host is initially at 

20 the APC1, and the APC1 acquires (100, 101) an IP address from the APS. 
The user IP context is established at the APC1 and the APS. The APS routes 
the datagrams to the APC1 . After a while, the mobile host roams to the APC2 
and a handover is initiated. The APC1 sends (102) the user IP context to the 
APC2, and the APC2 acknowledges (103) this. Having received the acknow- 

25 ledgement, the APC1 stores the new location for 40 minutes by default. Hav- 
ing sent the acknowledgement (103), the APC2 attempts to update (104) the 
location at the APS but fails because of a link failure. Forty minutes later the 
APS receives a new datagram. The APS forwards the datagram to the APC1 
according to the stored location information. Since the location timer has ex- 

30 pired at the APC1, the APC1 no longer knows the new location of the mobile 
host and discards the datagram and sends a destination remove request (105) 
to the APS. Having received the destination remove request from the APC1, 
the APS determines that the location of the mobile host is lost. The APS as- 
signs the user IP context a special state indicating that the IP address is in use 

35 but the location is unknown. When a new datagram arrives at the APS, the 
APS discards the datagram. 
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The description only illustrates preferred embodiments of the inven- 
tion. The invention is not, however, limited to these examples, but it may vary 
within the scope and spirit of the appended claims. 
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Claims 

1. A method for providing Internet Protocol-type, or IP-type, mobility 
for a mobile host in a mobile communications system comprising a plurality of 
mobile hosts (MH), at least two mobile exchanges (DXT1,DXT2), a plurality of 
5 base stations (TBS1.TBS2) connected to said mobile exchanges, at least one 
of the mobile exchanges being arranged to operate as a gateway which inter- 
faces the mobile communications system with external data networks (12), 
said method being characterized by the steps of 

allocating an IP address for a mobile host (MH), 
10 using a user identity and a data equipment identity for identifying 

the mobile host (MH) in the mobile communications system, 

defining the location of the mobile host by an identity of a mobile 
exchange (DXT1, DXT2) currently serving the mobile host (MH), 

establishing an address information which binds the allocated IP 
15 address to the user identity (SSI) and the data equipment identity (NSAPI), 
and which contains the location of the mobile host, 

routing IP datagrams having the allocated IP address from a gate- 
way exchange to the serving exchange and further to the respective mobile 
host (MH) according to said address information. 
20 2. A method according to claim 1, characterized by the steps 

of 

receiving at the serving mobile exchange (DXT1, DXT2) a datagram 
having the allocated IP address, 

sending said received datagram from the serving mobile exchange 
25 to the mobile host (MH) indicated by the user identity (SSI) and the data 
equipment identity (NSAPI) in said address information. 

3. A method according to claim 1 or 2, characterized by the 

step of 

updating the location of the mobile host (MH) in the address infor- 
30 mation in a handover from an old mobile exchange to a new mobile exchange. 

4. A method according to claim 3, characterized in that said 
handover comprises the steps of 

sending a roaming request from the mobile host to the old mobile 

exchange, 
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sending a roaming request from the old mobile exchange to the 
new mobile exchange, said roaming request containing said address informa- 
tion, 

updating said address information at the new mobile exchange, 
5 sending an acknowledgement from the new mobile exchange to the 

old mobile exchange, said acknowledgement containing the updated address 
information. 

5. A method according to claim 3 or 4, c h a r a c t e r i z e d by the 

step of 

10 storing said updated address information at the old mobile ex- 

change for a predetermined routing period, in order to enable routing of any 
subsequent datagram to the new mobile exchange. 

6. A method according to claim 3, 4 or 5, characterized by 
the steps of 

15 receiving, subsequent to the handover at the old mobile exchange, 

a datagram having the allocated IP address, 

sending, in response to said subsequent receipt of the datagram, a 
location update to an originating mobile exchange to indicate the new location 
of the IP address, 

20 routing, in response to said location update, any further datagrams 

having the allocated IP address to said new location. 

7. A method according to any one of claims 1 to 6, charac- 
terized by the step of 

maintaining the address information not only at the currently serving 
25 mobile exchange but also at a mobile exchange which manages the allocation 
of the IP address space to which the allocated IP address belongs, if the man- 
aging mobile exchange is not the same as the serving one. 

8. A method according to claim 7, characterized by the step 

of 

30 updating the location of the mobile host in said managing mobile 

exchange in response to a handover, if the managing mobile exchange is not 
the old exchange or the new exchange. 

9. A -method according to any one of claims 1 to 8, charac- 
terized by the steps of 

35 receiving a first datagram addressed to the allocated IP address at 

the gateway exchange from the external network, 
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requesting the location information for the IP address from a mobile 
exchange which manages the allocation of the IP address space to which the 
allocated IP address belongs if the managing mobile exchange is not the 
same as the gateway exchange, 
5 receiving the location information for the IP address from the man- 

aging exchange, 

routing the first datagram and any further datagrams having the al- 
located IP address to the serving mobile exchange indicated by said location 
information. 

10 10. A method according to claim 9, c h a r a c t e r i z e d by the 

steps of 

receiving at the gateway exchange a location update from the mo- 
bile exchange indicated by the location information, 

routing, in response to said location update, any further datagrams 
15 having the allocated IP address to a new location indicated in the location up- 
date. 

1 1 . A method according to claim 9 or 10, characterized by 
the steps of 

deleting the location information of the IP address at the gateway 
20 exchange when a predetermined period of time has elapsed from obtaining 
said location information or from the last reception of a datagram having the 
allocated IP address, 

re-requesting the location information of the IP address from the 
managing exchange if a datagram having the allocated IP address is received 
25 after the deletion. 

12. A method according to any one of claims 1 to 11, charac- 
terized in that the user identity is a mobile subscriber identity (SSI) and the 
data equipment identity is a network service point access identifier (NSAPI). 

13. A method according to any one of claims 1 to 12, charac- 
30 t e r i z e d by allocating the IP address to the mobile host dynamically, i.e. 

when it registers to the mobile communications system, or allocating the IP 
address permanently. 

14. A mobile communication system comprising 
a plurality of mobile hosts (MH), 
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at least two mobile exchanges (DXT1,DXT2), at least one of the 
mobile exchanges being arranged to operate as a gateway which interfaces 
the mobile communications system with external data networks (12) 

a plurality of base stations (TBS1,TBS2) connected to said mobile 
5 exchanges, 

and a mobility mechanism for providing Internet Protocol-type, or 
IP-type, mobility for the mobile hosts, 

characterized in that the mobility mechanism comprises 

the mobile exchanges (DXT1 , DXT2) arranged to use a user identity 
10 (SSI) and a data equipment identity (NSAPI) for identifying each mobile host 
(MH) and to use an identity of the mobile exchange (DXT1, DXT2) currently 
serving the mobile host for defining the location of the mobile host, 

each mobile host (MH) having a dynamically or permanently allo- 
cated IP address which is bound to the user identity, the data equipment iden- 
15 tity and the location information of the respective mobile host, 

the mobile exchanges (DXT1, DXT2) being arranged to route IP 
datagrams having the allocated IP address from a gateway exchange (DXT1) 
to the serving exchange (DXT2) according to the location information and fur- 
ther to the respective mobile host according to the user identity and the data 
20 equipment identity bound to the IP address. 

15. A system according to claim 14, characterized in that the 
mobile exchanges (DXT1 , DXT2) are arranged to update the location informa- 
tion in a handover from an old exchange to a new exchange. 

1 6. A system according to claim 15, characterized in that the 
25 old mobile exchange (DXT1 , DXT2) is arranged to maintain the updated loca- 
tion information for the allocated IP address for a predetermined routing pe- 
riod, in order to enable the routing of any further datagrams having the allo- 
cated IP address to the new exchange, and the old mobile exchange is further 
arranged to, in response to the receipt of said further datagrams having the 

30 allocated IP address, to update the location information of the IP address in an 
originating mobile exchange, typically in the gateway exchange, in order to al- 
low the originating exchange to reroute any further datagrams having the allo- 
cated IP address to said new location. 

17. A system according to claim 14, 15 or 16, c h a r a c t e r i z e d 
35 in that at least one of the exchanges (DXT1, DXT2) is arranged to function as 

an address pool server (ASP) which manages the entire IP address space in 
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the system or part of it, and that, in addition to the currently serving mobile ex- 
change, the address pool server (ASP) managing the IP address space to 
which the allocated IP address belongs is arranged to store the location, the 
user identity and the data equipment identity bound to the IP address, and that 
5 the new exchange is arranged to update the location of the mobile host in said 
address pool server (ASP) in response to a hand- over. 

1 8. A system according to claim 17, characterized in that the 
gateway exchange is responsive to receiving a first datagram addressed to the 
allocated IP address from the external network, for requesting the location in- 

10 formation for the IP address from the respective address pool server (ASP) 
and for routing the first datagram and any further datagrams having the allo- 
cated IP address to the serving mobile exchange indicated by said location 
information. 

19. A system according to any one of claims 14 to 18, c h a r a c - 
15 t e r i z e d in that the user identity is a mobile subscriber identity (SSI) and the 

data equipment identity is a network service point access identifier (NSAPI). 
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